1. Field of Invention
This invention relates to the generation of simulation models for electronic hardware systems. The models implement the abstraction mappings defined between the signals of a system specification model and those of a system implementation model, where the abstraction mappings are themselves expressed using a new type of specification language, termed an "abstraction language." The models created by the invention have a number of uses that include implementing key portions of simulation test bench models that control the testing of design models in multi-level simulation environments.
2. Description of Prior Art
In the development of digital electronic hardware systems, design engineers use a broad range of tools to generate and analyze models of an intended system prior to its fabrication. These tools contribute to large savings in the time and money needed to develop hardware systems by supporting the efficient generation of detailed implementation models from abstract specification models, and the detection of design mistakes early in the design process. A typical tool suite includes behavioral languages and simulators to model and exercise hardware systems at many different levels of abstraction.
For hardware expressed at low levels of abstraction, design engineers have access to commercial tools that successfully automate many design steps. For instance, these tools can synthesize integrated circuit layouts directly from design descriptions written in standard hardware description languages. The models that are input to these synthesis tools are generally written at a level of abstraction called the register-transfer level (or RTL). At this level the input and output signals of the design are represented as bits and bit vectors. Behavior is defined over these signals for every step of the system clock. RTL descriptions for complex circuits can easily fill many tens or hundreds of pages.
Because of the high complexity of RTL models, it is normally quite difficult to determine from them whether they represent a system meeting the system requirements or not. Because of this, when a requirements model is constructed for a system, the usual approach is to build it at a level of abstraction much above RTL. The term `behavioral` level is usually given to this abstract specification level. Because of the simplicity of behavioral models, they are relatively easy to analyze and, if written in an executable language, quick to test through simulation. Behavioral models represent excellent specifications for RTL models in a top-down design paradigm.
Beginning from a well-analyzed and -tested behavioral specification model, the problem of generating an implementing RTL model can be difficult because of the vast differences in the levels of abstraction for the specification and the implementation. For example, in contrast to the bits and bit vectors of RTL models, behavioral models often employ more complex data types such as arrays, records, and enumerated types. Furthermore, the time steps used at the behavioral level might represent long sequences of RTL time steps.
For the vast majority of digital hardware design efforts today, design engineers manually construct RTL models from behavioral specifications or other informal models and ideas, and then verify the RTL models through simulation. In the past, designers verified implementation models by explicitly generating and then applying test vectors to the model. Implementation model correctness was determined by observing how well the resulting state and output changes matched their expected values. However, this approach requires a level of effort at simulation time that is normally considered to be excessive today for complex systems.
Today, a more common simulation practice is to automate much of the detailed interaction with the implementation model within a second simulation model acting as the environment for the implementation. Such environment models, often called `test benches,` can vary quite drastically in their ability to reduce the designer workload at simulation time. At one extreme, the test bench might simply read input test vectors from a file, apply the vectors to the implementation model, and then write the implementation outputs to a second file. Such a test bench would be relatively easy to construct, but would offer little in the way of automation since the designer would still be required to generate the input vectors that are stored in the input file and to certify the results that were stored into the output file.
At the other extreme, sophisticated test benches can be constructed to not only apply test inputs to the implementation, but to also select the inputs to be applied. For the output side of the implementation, high-quality test benches would not simply forward the implementation results to an output file, but would instead certify the results against their expected values as defined by a behavioral specification. Test benches of this type are beneficial in two important respects. For one, the reduced simulation-time workload they offer hardware designers represents a direct savings in both time and money. Secondly, the increased automation used for the implementation input selection and the output certification decreases the risk of human error for these tasks. The increased rigor offered by the automation can be reflected in a more exhaustive coverage of the implementation input space, along with a lower likelihood of erroneous implementation outputs escaping detection.
A classic engineering tradeoff exists in the design of simulation test bench models. For high-quality test benches, clear benefits in simulation-time rigor and automation are countered by a greater design effort needed to construct the test bench. However, as hardware systems continue to become more complex, the tradeoff increasingly favors highly capable test benches in order to address the greater number of test cases that must be generated and analyzed. Unfortunately, the design of high-quality test benches becomes more difficult as the complexity of hardware systems increases. In fact, it is often observed today that building test benches for complex hardware implementation models can be as hard, or harder, than the construction of the implementation models themselves. It is clear that new methods and tools are needed to increase the efficiency of test bench construction over the manual methods prevalent today, and such tools should enhance the quality of the test benches that are produced.
The importance of the test bench generation problem is demonstrated by the large number of recently-described research efforts and commercial tools for automating test bench generation. The most widely used of these approaches generates test benches from interface protocol specifications expressed as timing diagrams over the input and output signals of the implementation model ED1,ED2,EE1,EE4--see appended references at end of description!. Timing diagrams are very useful for describing interface protocol behavior at the boundaries of implementation models, and have the advantage of being intuitive and easily understood by design engineers. However, an important weakness of timing diagrams is the relative incompleteness of the information that they convey. For example, timing diagrams fail to define the data processing, or functionality, of a circuit. Because of this, timing diagrams must be augmented with methods for specifying functionality in test bench tools that provide a highly desired automated certification of implementation model outputs against designer-specified behavior. Existing methods for adding this functionality are ad hoc and duplicate effort already required for behavioral specification modeling in top-down design environments.
Another approach to automated test bench generation converts graphical state machine-based specifications into test benches Arm,ED1!. This approach suffers an important disadvantage, however, in its lack of support for multi-level simulation environments. The state machines used in this approach, although graphical, express behavior for each step of the RTL system clock using the bits and bit-vectors of the RTL implementation. The test benches produced by this approach cannot verify RTL implementations against specifications whose operations process abstract data types or whose time steps cover multiple RTL time steps.
A third test bench generation approach generates test benches from specifications written in a new class of `verification languages` EE3!. However, although programs written in these languages can be more concise and easier to write than the underlying simulation programs, they still describe behavior with respect to the signals of the implementation; this approach therefore has the same problems with multi-level simulation environments as the previous approach. Because verification-language programs do not specify the mappings linking RTL implementation signals to a set of behavioral-level counterparts, the generated test benches cannot implement the mappings necessary for multi-level environments.
One approach to test bench generation known in the prior art is shown in FIG. 0. In this approach, the designer specifies one set of waveforms to be input to the implementation and a second set to serve as the basis for determining output correctness. The test bench implements the input driving and output certification precisely as defined by the waveforms input by the designer.
A number of other test bench generation approaches have been introduced in the past as well, all of which suffer from one or more disadvantages beyond the problems cited above. In summary, the fundamental problem with existing approaches is the failure to support multi-level simulation environments, where the system specification model resides at a higher level of data and temporal abstraction than the implementation model. The failure of these approaches to do so is easily explained, since none use input languages with the expressiveness necessary to specify the mappings needed to link implementations to abstract specifications. Without a specification for the mappings, the tools are incapable of implementing the mappings within their generated test benches.